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Abstract 


The  Tactical  Medical  Coordination  System  (TacMedCS)  provides  rapid  casualty  identification 
under  adverse  conditions,  enables  visibility  of  casualty  status  from  the  point  of  injury  through 
medical  treatment  in  higher  echelons  of  care,  maintains  an  electronic  treatment  record  with  the 
patient,  utilizes  non-physical-contact  data  transmission  and  storage  media,  and  uplinks  casualty 
information  to  a  theater  information  network.  Additionally,  the  current  version  of  TacMedCS 
provides  information  to  the  corpsman  in  the  field  about  patient  location  and  status  using  a  stand- 
along  handheld  device.  This  mature  prototype  (DoD  Technology  Readiness  Level  7)  was  tested  at 
Fleet  Hospital  3  during  Operation  Iraqi  Freedom  in  2003,  shipboard  in  the  Health  Services 
Support  Exercise  in  2004,  in  Coalition  Warrior  Interoperability  Demonstration  2005  where  it  was 
determined  to  be  a  top  performer,  and  during  several  Limited  Technology  Assessments  conducted 
at  the  Marine  Corps  Warfighting  Laboratory.  Near  real-time  awareness  of  casualty  status  and 
location  will  allow  medical  personnel  to  respond  with  needed  evacuation  resources  and  will 
facilitate  planning  for  treatment  of  incoming  casualties  by  more  quickly  identifying  the  resources 
required  to  treat  specific  injury  types  and  severity,  while  providing  medical  managers  with 


advanced  situational  awareness. 
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Patient  care  can  require  many  providers  who  may  be  in  different  locations  either  within  a 
medical  treatment  facility  (MTF),  or  at  different  MTFs.  Even  when  medical  care  is  provided  in  a 
fixed  facility,  such  as  a  hospital,  locating  patients  who  are  receiving  care  can  be  very  difficult.  These 
difficulties  are  magnified  when  the  patient  is  seriously  wounded  in  a  combat  zone,  and  may  need  to 
be  evacuated  through  several  levels  of  care  while  receiving  treatment.  Currently,  there  is  a  problem 
coordinating  this  care.  Providers  must  guess  what  the  previous  medical  treatment  was,  who  they 
could  contact  to  get  more  information,  or  even  who  the  patient’s  name.  Various  data  storage 
methodologies  to  communicate  information  about  patient  treatment  in  a  timely  manner  have  been 
tried,  such  as  computer  disks,  thumb  drives,  cassette  voice  recorders,  and  paper  records.  To  date, 
none  has  been  consistently  successful  in  communicating  patient  information  to  the  next  level  of  care. 
Some  providers  have  resorted  to  making  notes  on  the  patient’s  body  to  coordinate  care,  as  shown  in 
Figure  1. 


Figure  1.  Example  of  medical  provider  communication:  a  note  taped  to  the  patient. 

In  addition  to  the  problems  faced  by  medical  care  providers  coordinating  care  without  being 
able  to  share  information,  there  is  the  burden  on  the  unit  of  not  knowing  the  status  and  location  of  an 
injured  warfighter.  When  a  corpsman  provides  treatment  in  theater  and  takes  the  patient  to  the  next 
level  of  care,  that  corpsman  is  responsible  for  knowing  that  person’s  status.  The  current  system 
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requires  repeated  inquiries,  potentially  over  many  days,  to  determine  the  casualty’s  health  status. 
Automated  patient  tracking  would  both  facilitate  providing  coordinated  care  and  would  enable  the 
corpsman  to  determine  the  patient’s  location  and  status  more  quickly  and  with  less  effort  than  current 
methods. 

The  objective  of  the  Tactical  Medical  Coordination  System  (TacMedCS)  project 
was  to  identify  and  test  a  combination  of  technologies  to  facilitate  patient  tracking  across  all  levels  of 
medical  care.  The  system  needed  to  be  rugged  enough  to  function  in  austere  environments,  where  it 
could  be  subjected  to  climatological  extremes,  and  dirt,  sand,  and  water.  It  needed  to  be  flexible 
enough  to  support  both  combat  and  humanitarian  missions  and  function  in  areas  without  mature 
communications,  or  when  communication  systems  have  been  disabled.  To  contain  costs,  an 
additional  goal  was  to  make  use  of  commercial-off-the-shelf  (COTS)  equipment  as  much  as  possible 
rather  than  using  customized  development. 

System  Specifications 

TacMedCS  designers  decided  to  make  use  of  emerging  passive  radio  frequency  identification 
(RFID)  technology.  This  technology  allowed  automated  patient  identification,  and  offered  substantial 
advantages  to  alternative  technologies  such  as  optical  bar  codes.  RFID  allowed  patient  data  to  be 
stored  on  a  computer  chip  that  can  be  contained  within  a  plastic  bracelet  like  those  commonly  used 
for  patient  identification  in  hospitals.  This  chip  has  roughly  the  computing  power  of  the  original  IBM 
8088  computer.  The  specific  band  chosen,  which  is  13.56  MHz,  can  hold  2k  bytes  of  information  and 
has  the  capability  to  protect  some  of  the  data  from  future  overwriting  while  allowing  other  data  sets 
to  be  updated.  For  example,  the  serial  number  of  the  band  is  protected  from  overwriting,  while  patient 
encounters  information  can  be  updated.  RFID  offered  an  inexpensive,  durable,  reliable,  easy  to  use, 
and  safe  technology. 
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The  passive  RFID  system  chosen  is  inexpensive  to  implement.  Active  RFID  systems  have 
energized  tags  that  have  batteries  that  can  last  for  up  to  a  year.  The  passive  RFID  system  uses  tags 
that  have  only  a  circuit  that  is  powered  by  energy  from  the  RFID  reader/writer.  TacMedCS  system 
designers  chose  to  use  passive  tags  because  of  the  cost  difference  between  the  two  types  of  tags. 
Active  tags  are  more  expensive,  at  roughly  $150  per  tag,  compared  with  $l-$2  per  tag  for  passive 
tags. 

RFID  systems  are  durable.  The  RFID  chip  is  typically  encased  in  a  plastic  casing  to  enhance 
durability.  Unlike  a  bar  code,  the  RFID  chip  is  readable  even  when  the  tag  is  wet,  dirty,  or  abraded. 
The  tags  can  be  written  to  and  read  from  hundreds  of  times  without  failure.  Compromising  a  tag 
requires  the  band  be  crimped  through  the  circuit  that  forms  the  RFID  chip,  so  that  the  circuit  is 
disabled. 

RFID  systems  are  reliable.  Data  on  the  chips  can  be  encrypted  to  protect  them  from 
compromise  by  being  written  to  or  read  from  by  an  unauthorized  source.  Information  read  from  the 
band  is  not  susceptible  to  transcription  errors  or  difficulties  from  reading  handwriting.  Once  the 
information  is  stored  on  the  band,  unless  the  band  is  badly  damaged,  the  information  will  be  available 
indefinitely. 

RFID  systems  are  easy  to  use.  The  tag  can  be  read  without  physical  or  optical  contact  and  can 
even  be  read  through  Mission-Oriented  Protective  Posture  Level  IV  (MOPP-IV)  protective  clothing. 
Gathering  accurate  patient  information  requires  a  matter  of  seconds.  Similarly,  after  recording  a 
medical  encounter,  data  transfer  from  the  reader/writer  to  the  band  only  requires  seconds. 

Passive  RFID  systems  are  safe  to  use.  The  RFID  reader/writer  communicates  to  the  chip 
through  the  use  of  radio  waves,  which  are  believed  to  be  harmless.  The  satellite  transceiver  used  in 
the  current  version  of  the  system  has  undergone  and  passed  Hazards  of  Electromagnetic  Radiation  to 
Ordnance  (HERO),  Personnel  (HERP),  and  Fuel  (HERF)  testing  at  Naval  Surface  Warfare  Center 
Dahlgren.  HERO  refers  to  the  danger  of  accidental  activation  of  ordnance  because  of  radio  frequency 
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(RF)  electromagnetic  fields.  HERP  refers  to  the  danger  of  RF  electromagnetic  fields  to  the  health  of 
personnel.  HERF  refers  to  the  danger  of  RF  electromagnetic  fields  accidentally  igniting  volatile 
materials  (fuels).  The  entire  unit,  with  the  reader/writer,  will  be  tested  for  HERO,  HERP,  and  HERF 
as  soon  as  it  becomes  available. 

Concept  of  Operation 

TacMedCS  uses  an  RFID  chip  that  resides  in  a  band  placed  on  the  patient’s  wrist  to  store  a 
small  amount  of  patient  information,  such  as  the  person’s  name,  social  security  number  or  other 
identifying  number,  and  codes  for  where  the  patient  came  from  and  the  patient’s  expected 
disposition.  This  information  can  be  written  onto  the  tag  either  using  a  handheld,  dedicated  RFID 
reader/writer  or  using  an  RFID  card  inserted  into  a  laptop  or  desktop  computer.  When  the  tag  is 
read,  this  information  can  be  uploaded  to  a  local  medical  database  by  using  an  RFID-enabled 
computer.  From  there,  the  data  can  be  sent  elsewhere  using  established  networks,  such  as  the 
Internet,  NIPRNet,  or  SIPRNet.  In  the  absence  of  connectivity,  or  mature  communication 
infrastructure,  the  data  can  be  sent  via  satellite  phone  to  a  central  server,  and  access  can  be  provided 
to  other  locations — according  to  system  design,  as  shown  in  Figure  2.  Incorporation  of  satellite 
communication,  using  the  Iridium  network  of  satellites  (Iridium  Satellite  LLC),  enables  over-the- 
horizon  communications  and  may  provide  the  only  method  of  communication  in  austere  conditions. 


Figure  2.  TacMedCS  system  architecture. 
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The  incorporation  of  satellite  communication  capability  into  system  design  can  dramatically 
increase  system  costs.  Satellite  phones  can  be  an  order  of  magnitude  more  expensive  than  cell 
phones,  and  the  connection  time  is  also  expensive.  However,  satellite  communication  capabilities  can 
provide  patient  tracking  information  in  the  absence  of  standard  communication  infrastructure,  and  it 
ensures  that  the  system  can  operate  under  any  conditions.  Recent  technological  advances  allow  more- 
affordable  satellite  communication. 

After  the  data  are  transmitted  to  a  central  server,  the  casualty  information  can  be  displayed 
using  a  graphical  user  interface  (GUI)  such  as  the  Medical  Common  Operational  Picture  (MedCOP) 
or  the  Force  Medical  Tool  Set  (ForceMed;  ScenPro  Inc.,  Richardson,  Texas).  These  interfaces  allow 
the  user  to  query  the  data  so  that  patient  status  can  be  determined,  which  is  demonstrated  in  Figure  3. 


Figure  3.  Operator  using  the  TacMedCS  laptop  version  during  Fleet  Hospital  3  trial. 

If  the  data  cannot  be  transmitted  (e.g.,  because  of  a  communication  blackout),  the  patient’s 
data  are  stored  on  the  patient’s  tag.  For  Versions  IV  and  V,  patient  information  is  encrypted  at  192-bit 
or  the  advanced  encryption  standard  (AES)  level  of  encryption,  also  referred  to  as  FIPS- 197,  to 
ensure  the  security  of  the  information,  and  to  facilitate  obtaining  Defense  Information  Assurance 
Certification  and  Accreditation  Process  approval  for  the  system.  With  this  level  of  encryption,  the  tag 


can  hold  information  for  the  last  three  medical  encounters. 
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Recording  patient  data  on  the  tags  ensures  that  some  information  travels  with  the  patient  to 
the  next  level  of  care,  where  these  data  can  be  uploaded  into  the  system.  This  redundant  data  storage 
helps  ensure  that  the  patient  tracking  system  will  operate  reliably — even  when  providers  are  unable  to 
upload  the  data. 

Initial  versions  of  the  system  provided  the  capability  to  either  use  a  prepopulated  tag  that  had 
been  issued  to  a  Marine,  or  to  create  a  tag  for  a  person  who  did  not  have  one.  The  concept  behind  the 
prepopulated  tag  was  that  each  Marine  in  a  unit  would  be  issued  a  tag  with  his  or  her  information  on 
the  tag,  which  he  or  she  would  carry.  Doing  this  required  the  approval  of  and  funding  by  the  Marine 
Corps.  This  possibility  was  discussed,  but  was  never  adopted.  Subsequent  versions  of  the  system 
allow  the  use  of  a  prepopulated  tag.  However,  there  is  no  expectation  that  patients  will  have  them. 

Project  History 

The  TacMedCS  concept  was  first  envisioned  by  researchers  at  the  Naval  Aerospace  Medical 
Research  Laboratory  (NAMRL)  in  Pensacola,  Florida.  In  response  to  the  need  for  a  technology  that 
would  easily  and  unobtrusively  track  casualties  in  a  battlefield  environment,  they  tried  to  develop  this 
capability. 

At  the  time  they  began  this  project,  there  was  no  commercially  available  RF  identification 
chip,  which  was  a  crucial  to  the  project.  Within  2  years  of  NAMRL’s  inception  of  this  project,  RFID 
tags  and  reader/writer  devices  became  commercially  available.  As  COTS  hardware  became  available, 
it  was  incorporated  into  system  design.  When  COTS  hardware  could  not  do  what  was  required, 
customized  systems  were  designed  and  built. 

The  first  system  was  a  prototype,  which  was  large  and  clumsy,  but  could  fit  into  a  suitcase. 
Version  I  provided  a  proof  of  concept  that  an  RFID-based  patient  tracking  system  could  work  (Figure 


4). 
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Figure  4.  TacMedCS,  Version  I. 

As  the  commercial  sector  provided  more  choices,  the  patient  tracking  system  became  more 
compact,  more  rugged,  less  expensive,  and  the  project  became  more  feasible.  A  second  system  was 
developed  for  the  Marine  Corps  Chemical  Biological  Response  Force  (CBIRF;  Figure  5).  This 
system  tracked  the  location  of  casualties  as  well  as  responders.  It  was  tested  during  the  first  Limited 
Technology  Assessment  (LTA  1)  conducted  at  the  Marine  Corps  Warfighting  Laboratory  (MCWL) 
during  the  winter  of  2003. 


Figure  5.  TacMedCS  Version  II,  used  by  CBIRF. 
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The  next  version  of  the  project  took  advantage  of  COTS.  Version  III  had  handheld 
reader/writers,  the  Minec  4x,  and  was  a  substantial  advance  over  the  first  system  in  portability.  This 
system  is  shown  in  Figure  6.  This  version  and  subsequent  versions  only  tracked  casualties  rather  than 
tracking  both  casualties  and  responders. 


Figure  6.  Version  III  during  OIF  field  test. 


Version  III  was  successfully  field  tested  at  Fleet  Hospital  3  during  Operation  Iraqi  Freedom 
(OIF)  to  demonstrate  concept  feasibility.  It  was  used  to  locate  patients  within  the  hospital,  which 
consisted  of  an  interconnected  series  of  tents  and  buildings,  as  shown  in  Figure  7.  The  system 
architecture  for  this  field  test  is  shown  in  Figure  8.  Patient  information  from  casualty  receiving, 
intensive  care,  wards,  and  evacuation  was  transmitted  to  a  central  server.  This  server  could  provide 
the  data  to  other  computers  in  the  facility  through  a  Local  Area  Network  or  LAN.  This  test  did  not 
involve  any  satellite  communication. 

The  idea  of  automated  patient  identification  and  tracking  was  enthusiastically  received  by 
care  providers.  In  this  circumstance,  not  only  did  they  have  to  locate  injured  Marines,  but  they  also 
had  to  track  indigenous  people  who  had  been  wounded,  and  who  might  not  be  forthcoming  about 
their  identity  (Figure  9).  So  TacMedCS  provided  a  way  of  tracking  patients  with  similar  names, 
deceptive  patients,  and  children  who  were  unable  to  provide  good  information  and  history. 
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Figure  7.  Fleet  Hospital  3. 


Figure  8.  Architecture  for  Fleet  Hospital  3  test. 


Figure  9.  A  foreign  patient  who  has  been  banded  for  identification. 

The  capabilities  of  the  third  system  were  later  extended  to  accommodate  data  transfer  using  a 
satellite  phone.  Patient  data  were  transmitted  via  satellite  phone  to  the  Iridium  satellite  system 
consisting  of  72  satellites  in  low  earth  orbit.  The  signal  was  received  by  the  closest  satellite,  and 
passed  along  until  it  was  sent  to  a  gateway  in  Wahiawa,  Hawaii.  There  it  was  transmitted  by  the 
Defense  Information  Systems  Agency  to  a  server.  From  there,  the  data  were  provided  to  authorized 
users  over  the  Internet.  The  Enhanced  Version  III  was  tested  during  LTA  2,  which  was  conducted  in 
the  summer  of  2004  (Wilson  &  Nebelkopf,  2005),  and  in  LTA  3,  which  was  conducted  in  the  fall  of 
2004  (Wilson,  2005).  Figure  10  shows  Version  III  being  tested  during  an  LTA. 
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Figure  10.  TacMedCS  Enhanced  Version  III  during  an  LTA. 

This  enhanced  version  was  used  during  participation  in  a  Health  Services  Support  Exercise  in 

2004  aboard  the  HSV-2  Swift.  During  this  test,  system  users  were  able  to  write  to  and  read  from  the 
tag  in  the  shipboard  environment.  Fictitious  patient  information  was  transmitted  via  satellite  phone  to 
a  server  in  Johnstown,  Pennsylvania.  From  there,  the  data  were  available  over  the  Internet. 

We  were  unable  to  send  the  data  via  satellite  phone  to  the  server.  The  TacMedCS  data  listener 
had  been  constructed  to  only  accept  characters  that  it  expected.  When  it  received  unexpected 
characters,  the  listener  stopped  working,  and  the  system  had  to  be  shut  down  and  restarted.  This 
problem  was  addressed  by  rewriting  the  listener  to  ignore  unexpected  characters,  which  helped 
ensure  system  reliability. 

The  enhanced  version  was  also  tested  in  the  Coalition  Warrior  Interoperability  Demonstration 

2005  (CWID)  at  sites  in  Dahlgren,  Colorado  Springs,  San  Diego,  and  New  Zealand,  where  the  system 
was  determined  to  be  a  top  performer.  The  system  architecture  for  CWID  2005  is  shown  in  Figure  11. 
For  this  exercise,  the  server  was  housed  at  MCWF. 
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Figure  11.  CWID  2005  system  architecture. 

The  Enhanced  Version  III  system  had  several  advantages  over  previous  systems,  but  it  also 
had  limitations.  The  advantages  of  the  system  were  that  all  the  hardware  was  COTS,  making  it  less 
expensive  and  more  reliable  than  customized  development,  and  it  was  very  portable.  The 
disadvantages  to  the  system  were  that  the  Minec  scanner  lacked  a  complete  keyboard  and  required 
the  operator  to  press  two  keys  to  enter  each  letter.  This  made  data  entry  using  the  handheld  unit  quite 
burdensome.  Data  entry  could  be  accomplished,  but  it  could  not  be  done  quickly  or  easily.  In 
addition,  the  satellite  phone  had  to  be  physically  connected  to  the  scanner.  If  the  two  units  were  left 
connected,  the  phone  had  to  be  placed  somewhere  or  held  while  entering  the  data  into  the  handheld. 

If  the  satellite  phone  was  disconnected,  it  was  easier  to  enter  the  data  into  the  Minec  reader/writer. 
However,  with  repeated  reconnection,  the  connection  could  become  contaminated  with  fine  sand,  and 
fail.  Estimates  were  that  disconnection  and  reconnection  could  be  done  about  10  times  before  the 
connection  would  cease  to  function. 

The  fourth  system,  developed  by  MCWL,  included  a  satellite  phone  built  into  the  device. 
Version  IV  (the  ACC  6100,  shown  in  Figure  12)  had  the  advantage  that  the  satellite  phone  did  not 


have  to  be  cabled  to  the  RFID  reader/writer  to  communicate  the  data  to  a  more  central  location.  This 
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feature  was  important  during  desert  operation  because  of  the  problems  produced  by  the  fine  sand.  To 
create  a  reliable  system,  the  satellite  phone  was  incorporated  into  the  box  that  housed  the  RFID 
reader/writer. 


Figure  12.  Version  IV  integrated  handset. 


Data  transmission  from  the  satellite  modem  to  the  satellite  was  also  changed  from  sending  a 
sequential  signal  to  sending  data  in  bursts.  This  method  of  communication  does  not  support  voice 
transmission,  but  it  is  more  efficient  for  sending  data,  and  allows  faster  transmission  of  data — which 
provides  a  greater  margin  of  safety  for  the  personnel  transmitting  the  data.  Use  of  a  satellite  phone 
requires  a  line  of  sight  between  the  user  and  the  satellite.  Users  sending  a  sequential  signal  are  more 
vulnerable  to  detection. 

As  part  of  migrating  the  application  to  a  new  platform,  the  user  interface  was  redesigned  to 
make  better  use  of  the  high-fidelity  color  display  that  was  part  of  the  new  platform  by  providing 
redundant  cues  to  facilitate  user  navigation  of  the  complicated  software  system.  The  previous 
interface  used  black  and  white  icons  for  different  functions,  such  as  initializing  the  system,  reading  or 
writing  to  tags,  and  communicating  the  information  to  the  satellite  phone.  If  a  user  selected  the  wrong 
icon,  the  system  would  present  screens  that  could  be  confusing  to  the  user.  With  new,  inexperienced 
users,  who  would  be  expected  to  occasionally  select  the  wrong  icon,  the  system  could  seem  too 
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complicated  to  use,  and  might  be  rejected  before  the  user  had  enough  familiarity  to  learn  to  use  it 
correctly. 

In  the  revised  interface,  each  function  is  shown  in  a  colored  stripe  as  seen  in  Figure  13. 
Selection  of  the  function  sequentially  leads  to  more  windows  that  had  the  same  colored  bar  at  the  top 
of  the  window,  with  the  name  of  the  function  at  the  top  of  the  page.  If  the  operator  intended  to  select 
one  function,  and  selected  another  function  by  mistake,  there  was  feedback  provided  on  the  screen, 
both  from  the  color  and  the  name  of  the  function  showing  the  operator  where  he  or  she  was  within  the 
program.  This  was  intended  to  reduce  confusion  regarding  why  the  system  might  be  behaving 
differently  from  the  operator’s  expectations,  increase  user  satisfaction  with  the  system,  and  decrease 
the  user’s  belief  that  correct  system  operation  was  an  undocumented  error  in  the  software. 


Figure  13.  Sample  screen  shot  from  revised  TacMedCS  interface,  Version  IV. 

As  the  product  development  team  used  the  integrated  handset,  and  sent  the  handsets  to  other 

team  locations,  we  learned  that  the  handsets  were  frequently  broken  during  shipment.  To  repair  these 
handsets,  they  had  to  be  returned  to  the  manufacturer,  where  the  case  was  opened,  the  equipment  was 
repaired,  and  the  assembly  had  to  be  resealed  into  the  case.  Although  this  unit  was  impervious  to  sand 
and  functioned,  it  was  not  sufficiently  rugged  to  withstand  the  shock  experienced  during  shipping. 
Presumably,  it  would  not  be  able  to  withstand  field  conditions. 
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Additionally,  we  noticed  that  the  battery  life  was  not  sufficient  for  field  operations.  The 
batteries  did  not  support  both  the  customized  handheld  unit  and  the  integrated  handheld  unit  as  well 
as  we  had  hoped. 

Version  IV  was  tested  during  LTA  4,  which  was  conducted  in  the  summer  of  2005,  and 
during  LTA  5,  which  was  conducted  both  at  MCWL  and  at  ScenPro  Headquarters  in  Richardson, 
Texas,  also  in  the  summer  of  2005  (Fye,  2006).  The  system  architecture  was  comparable  to  the 
architecture  used  in  CWID  2005. 

Current  Version 

The  fifth  system  resides  on  an  iPAC  Pocket  PC  (Hewlett-Packard  Company;  Figure  14).  This 
device  was  chosen  to  be  compatible  with  the  Armed  Forces  Health  Longitudinal  Technology 
Application  (AHLTA)  Mobile  development  (formerly  called  BMIS-T)  so  that  TacMedCS  capability 
could  be  implemented  at  minimal  cost.  Given  the  tremendous  number  of  AHLTA  Mobile  units  that 
have  been  and  continue  to  be  deployed,  and  the  overall  success  and  acceptance  of  this  project,  having 
TacMedCS  functionality  on  AHLTA  Mobile  hardware  both  increases  the  chances  of  system 
deployment  and  provides  a  transition  plan  for  this  project. 


Figure  14.  iPAQ  Pocket  PC  using  Tradewinds  RFID  card,  running  TacMedCS. 
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In  addition  to  being  compatible  with  AHLTA  Mobile,  there  were  several  other  goals  of  this 
development  effort.  We  wanted  to  take  advantage  of  improvements  in  satellite  communication 
technology,  which  had  dramatically  decreased  the  purchase  cost  of  this  technology  to  about  $300- 
$400  per  unit  and  decreased  the  power  consumption  by  about  an  order  of  magnitude.  We  wanted  to 
maintain  the  short-burst  transmission  capability  that  was  introduced  in  Version  IV.  Version  V  allows 
for  satellite  communication  of  data  by  inserting  the  Pocket  PC  device  into  a  sled  that  has  a 
customized  circuitry  to  allow  short-burst  satellite  communications  (Figure  15).  Version  V  was 
successfully  tested  during  LTA  6  in  May  of  2007  (Fye,  2007). 


Figure  15.  TacMedCS  Version  V:  a  compact,  fully  integrated  handset  and  satellite  modem. 

This  construction  allows  use  of  COTS  technology  for  the  main  unit  of  the  system.  The  Pocket 
PC  and  the  additional  circuitry  to  support  the  satellite  communication  is  housed  in  a  vinyl  casing  to 
make  it  resistant  to  the  elements  and  provide  some  protection  from  shock.  It  has  a  flip-up  cover  to 
protect  the  screen  while  still  providing  access  to  the  user.  The  unit  is  powered  by  a  separate  power 
supply,  housed  in  the  unit,  which  uses  three  AA  batteries. 

A  unit  similar  to  Version  V,  Version  V-Lite  that  does  not  have  the  satellite  communication 
capability,  could  be  fielded  as  soon  as  funding  becomes  available  to  supplement  system  capabilities. 
Although  users  in  some  locations  may  require  satellite  communications,  users  in  areas  with  more 
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mature  communications  infrastructure  will  not.  For  these  users,  satellite  capability  increases  unit 
weight  and  cost.  For  units  not  requiring  satellite  communications,  an  AHLTA  Mobile  unit  could  be 
fitted  with  either  an  AWID  RFID  reader/writer  card  in  the  PCMCIA  slot,  or  a  Tradewinds  RFID 
reader/writer  card  in  the  SDIO  slot,  for  under  $200  per  unit.  This  substantially  reduces  the  cost  of 
additional  units  and  allows  more  flexibility  in  system  implementation.  Similarly,  this  card  can  be 
used  in  existing  laptops  or  desktop  computers  to  provide  TacMedCS  functionality  quite 
inexpensively. 

Version  V  is  designed  for  viewing  using  the  ForceMed  GUI,  a  proprietary  software  suite  developed 
by  ScenPro.  The  system  architecture  is  shown  in  Figure  16. 


Figure  16.  Version  V  components  and  communication  architecture. 


Future  Development 

The  current  version  of  TacMedCS  can  support  patient  tracking  during  combat  situations.  With 
minimal  lead  time,  Version  V-Lite  could  inexpensively  provide  some  support  for  both  humanitarian 
use  and  homeland  defense.  The  standard  Version  V  is  not  a  COTS  product.  To  use  this  capability, 
units  would  have  to  be  procured  and  built,  the  software  loaded,  the  units  tested,  and  then  stored.  The 
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satellite  phone  usage  contracts  would  have  to  either  be  in  place  or  rapidly  completed.  In  contrast, 
Version  V-Lite  units  would  require  only  procurement,  and  loading  the  software. 

The  software  for  this  application  works  on  a  cell  phone  (Figure  17).  This  allows  an 
inexpensive  implementation  of  RFID-enabled  patient  or  provider  tracking  in  any  area  with  cell  phone 
service. 


Figure  17.  TacMedCS  on  a  cell  phone  equipped  with  Tradewinds  RFID  card. 

In  a  disaster  scenario  without  mature  communications,  cell  phone  capability  can  be  provided 
using  a  Cell  on  Wheels  (COW)  for  temporary  cell  phone  capability  when  roads  are  passable.  A  COW 
is  a  mobile  cell  site  that  consists  of  a  cellular  antenna  tower  and  electronic  radio  equipment  on  a  truck 
or  trailer.  One  system  architecture  is  shown  in  Figure  18. 
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Figure  18.  An  ad  hoc  system  architecture  to  deal  with  a  mass  casualty. 


Transition  Plan 

We  hope  to  transition  the  TacMedCS  capability  to  the  Theater  Medical  Information  Program- 
Joint  (TMIP-J),  a  Program  of  Record  through  our  relationship  with  AHLTA  Mobile  and  its 
developers.  Over  30,000  AHLTA  Mobile  units  have  been  fielded  by  Medical  Communications  for 
Combat  Casualty  Care,  the  Army’s  fielding  agent  for  TMIP.  The  TacMedCS  application  runs  on  the 
AHLTA  Mobile  hardware  as  a  separate  application.  There  are  plans  for  AHLTA  Mobile  developers 
to  incorporate  TacMedCS  functionality  into  the  AHLTA  Mobile  program.  TMIP-J  has  adopted  the 
AHLTA  Mobile  program. 

Development  Team 

This  project  has  been  a  collaborative  effort  among  multiple  commands  and  engineering  firms. 
NAMRL  started  the  project  in  1999  and  continued  development  of  it  for  several  years.  NAMRL 
researchers  chose  to  use  contactless  RFID  technology  to  eliminate  the  problems  that  were 
experienced  by  systems  relying  on  data  transfer  using  the  Personal  Information  Carrier  (PIC)  card, 
which  did  not  perform  well  in  field  conditions.  NAMRL  originally  partnered  with  Battelle  to  support 
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this  effort,  which  was  funded  by  the  Office  of  Naval  Research.  Funding  was  obtained  from  the 
Defense  Advanced  Research  Projects  Agency  in  2001  as  a  part  of  a  program  called  the  Enhanced 
Consequence  Management  Planning  and  Support  System  (ENCOMPASS).  The  purpose  of  this 
program  was  to  provide  a  suite  of  tools  designed  to  help  manage  the  response  to  catastrophes  and  to 
track  the  victims.  Technical  support  for  the  ENCOMPASS  effort  and  subsequent  efforts  were 
provided  by  ScenPro.  ScenPro  staff  did  the  design  and  coding  of  the  computer  programs  for  the 
handheld  RFID  reader/writer,  the  laptop  version,  communication  with  the  satellite  phone,  and  the 
GUI,  initially  MedCOP,  and  then  ForceMed,  which  was  used  to  view  the  data.  They  conducted  in- 
house  testing,  support  for  field  tests,  military  exercises  and  demonstrations,  created  user  guides,  and 
provided  project  documentation. 

The  U.S  Navy  Bureau  of  Medicine  and  Surgery  (BUMED)  provided  funding  for  further 
development  and  for  field  testing  the  unit  during  OIF.  BUMED  sponsored  the  project  and  provided 
technical  direction. 

In  2003,  MCWL  became  involved  by  providing  technical  guidance  and  ongoing  testing.  The 
experimental  test  design  for  each  LTA  was  provided  by  the  Center  for  Naval  Analysis  staff,  who 
analyzed  and  interpreted  the  resulting  data,  and  wrote  the  test  report.  U.S.  Marine  Corps 
Headquarters,  Health  Services,  provided  project  support  and  guidance. 

Naval  Health  Research  Center  became  involved  in  the  project  early  in  2004.  NHRC  provided 
project  management  support,  ergonomic  and  regulatory  advice,  and  support  for  field  testing  and 
military  exercises.  To  coordinate  this  project,  NHRC  hosted  periodic  video  conferences  and  later 
teleconferences,  which  facilitated  communication  among  the  many  different  agencies  involved. 

NAL  Research  Corporation  (Manassas,  VA)  constructed  the  satellite  modem  that  replaced  the 
satellite  phone  in  Versions  IV  and  V.  A.C.C.  Systems  Inc.  (Glen  Head,  NY)  provided  the  tags  and 
labeling,  as  well  as  fabricated  Version  IV  and  the  sled  for  Version  V. 
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MTS  Technologies,  Inc.  (Arlington,  VA)  modified  the  data  warehouse  that  holds  the  data 
gathered  by  the  Naval  Medical  Knowledge  Management  System  (NavMedKMS)  to  accommodate 
TacMedCS  data.  MTS  also  provided  support  for  participation  in  CWID  2005,  and  engineering 
support  and  guidance. 

Conclusion 

TacMedCS  can  be  used  to  display  near  real-time  casualty  data  in  the  field,  providing  both 
medical  and  tactical  benefits.  Near  real-time  awareness  of  casualty  status  and  location  will  allow 
medical  personnel  to  respond  with  needed  evacuation  resources  and  will  facilitate  planning  for 
treatment  of  incoming  casualties  by  more  quickly  identifying  the  resources  required  to  treat  specific 
injury  types  and  severity,  while  providing  medical  managers  with  advanced  situational  awareness. 
Additionally,  the  current  TacMedCS  version  handset  can  provide  information  to  the  corpsman  about 
patient  location  and  status  for  the  patients  he  or  she  has  treated.  This  relieves  the  corpsman  of  the 
responsibility  to  track  down  casualty  status. 

This  system  has  evolved  from  an  improvised  device  to  a  mature  prototype  at  Level  7  in  the 
framework  of  the  Department  of  Defense  (DoD)  Technology  Readiness  Levels  (see  Appendix  1).  It 
has  been  repeatedly  tested  in  LTAs,  in  military  exercises,  and  during  combat.  It  can  currently  support 
patient  tracking  during  combat  situations,  and  could  support  humanitarian  use  and  homeland  defense 
with  minimal  modification  (Figure  18). 
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Figure  18.  A  child  banded  during  Fleet  Hospital  3  trial. 

Automated  patient  tracking  has  a  variety  of  benefits.  It  could  enhance  communication  among 
medical  care  providers.  This  could  affect  not  only  the  stream  of  patients  being  treated,  but  it  could 
also  influence  best  practices  about  how  to  treat  patients  in  the  future,  which  might  be  incorporated 
into  new  policies.  As  an  example  of  how  TacMedCS  could  improve  patient  care,  patient  tracking 
capability  could  allow  providers  to  determine  who  last  provided  treatment  to  the  patient,  and  could 
facilitate  communication  among  providers  to  decrease  the  number  of  redundant  surgeries  performed. 

Patient  tracking  capability  could  also  help  refine  the  provision  of  medical  care  during  combat. 
Currently,  given  the  lack  of  information  about  the  medical  care  provided  to  patients,  it  is  very 
difficult  to  do  an  outcomes-based  analysis  of  various  treatments.  Some  care  providers  are  responding 
to  evolving  threats  with  innovative  care.  Some  of  these  innovations  are  improvements  over 
previously  used  techniques  and  some  are  not.  Providing  information  about  where  the  patient  has  been 
could  be  useful  in  determining  what  treatment  each  patient  received.  When  combined  with  the 
patient’s  outcome,  this  information  could  allow  medical  analysts  to  determine  the  success  of  various 
treatments,  which  would  be  useful  information  for  medical  care  providers. 

TacMedCS  is  a  mature  technology  that  primarily  uses  COTS  technology  to  provide  a  needed 
capability.  TacMedCS  is  a  good  candidate  for  adoption  into  the  TMIP  suite  of  applications,  and  for 


consideration  for  both  humanitarian  use  and  homeland  defense. 
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Appendix  1.  Technology  Readiness  Levels  in  the  Department  of  Defense 


Technology  Readiness  Levels  in  the  Department  of  Defense  (DOD) 

(Source:  DOD  (2006),  Defense  Acquisition  Guidebook) 

Technology  Readiness  Level 

Description 

1.  Basic  principles  observed 
and  reported 

Lowest  level  of  technology  readiness.  Scientific  research  begins  to  be 
translated  into  applied  research  and  development.  Example  might  include 
paper  studies  of  a  technology's  basic  properties. 

2.  Technology  concept  and/or 
application  formulated 

Invention  begins.  Once  basic  principles  are  observed,  practical 
applications  can  be  invented.  The  application  is  speculative  and  there  is 
no  proof  or  detailed  analysis  to  support  the  assumption.  Examples  are 
still  limited  to  paper  studies. 

3.  Analytical  and  experimental 
critical  function  and/or 
characteristic  proof  of  concept 

Active  research  and  development  is  initiated.  This  includes  analytical 
studies  and  laboratory  studies  to  physically  validate  analytical  predictions 
of  separate  elements  of  the  technology.  Examples  include  components 
that  are  not  yet  integrated  or  representative. 

4.  Component  and/or 
breadboard  validation  in 
laboratory  environment 

Basic  technological  components  are  integrated  to  establish  that  the  pieces 
will  work  together.  This  is  relatively  “low  fidelity”  compared  to  the 
eventual  system.  Examples  include  integration  of  'ad  hoc'  hardware  in  a 
laboratory. 

5.  Component  and/or 
breadboard  validation  in 
relevant  environment 

Fidelity  of  breadboard  technology  increases  significantly.  The  basic 
technological  components  are  integrated  with  reasonably  realistic 
supporting  elements  so  that  the  technology  can  be  tested  in  a  simulated 
environment.  Examples  include  'high  fidelity'  laboratory  integration  of 
components. 

6.  System/subsystem  model  or 
prototype  demonstration  in  a 
relevant  environment 

Representative  model  or  prototype  system,  which  is  well  beyond  the 
breadboard  tested  for  TRL  5,  is  tested  in  a  relevant  environment. 
Represents  a  major  step  up  in  a  technology’s  demonstrated  readiness. 
Examples  include  testing  a  prototype  in  a  high  fidelity  laboratory 
environment  or  in  simulated  operational  environment. 

7.  System  prototype 
demonstration  in  an  operational 
environment 

Prototype  near  or  at  planned  operational  system.  Represents  a  major  step 
up  from  TRL  6,  requiring  the  demonstration  of  an  actual  system 
prototype  in  an  operational  environment,  such  as  in  an  aircraft,  vehicle, 
or  space.  Examples  include  testing  the  prototype  in  a  test  bed  aircraft. 

8.  Actual  system  completed  and 
'flight  qualified'  through  test 
and  demonstration 

Technology  has  been  proven  to  work  in  its  final  form  and  under  expected 
conditions.  In  almost  all  cases,  this  TRL  represents  the  end  of  true  system 
development.  Examples  include  developmental  test  and  evaluation  of  the 
system  in  its  intended  weapon  system  to  determine  if  it  meets  design 
specifications. 

9.  Actual  system  'flight  proven' 
through  successful  mission 
operations 

Actual  application  of  the  technology  in  its  final  form  and  under  mission 
conditions,  such  as  those  encountered  in  operational  test  and  evaluation. 

In  almost  all  cases,  this  is  the  end  of  the  last  “bug  fixing”  aspects  of  true 
system  development.  Examples  include  using  the  system  under 
operational  mission  conditions. 
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Feb  2004-June  2007 


5a.  Contract  Number: 
5b.  Grant  Number 

5c.  Program  Element: 

603729N 

5d.  Project  Number: 

9162 

5e.  Task  Number: 

0 

5f.  Work  Unit  Number: 

60407,  60618 

9.  PERFORMING  ORGANIZATION  REPORT 
NUMBER 

Tech  Doc  No.  07-91 


10.  Sponsor/Monitor's  Acronyms(s) 

BUMED/NMRC/NMSC _ 

11.  Sponsor/Monitor's  Report  Number(s) 


